Internet Info 1994 March

home *** CD-ROM | disk | FTP | other *** search

/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / standards / iso / iso8649.asc < prev next >

Wrap

Text File | 1993-07-15 | 70.5 KB | 1,424 lines

Recommendation X.217 ASSOCIATION CONTROL SERVICE DEFINITION FOR OPEN SYSTEMS INTERCONNECTION FOR CCITT APPLICATIONS1 (Melbourne, 1988) The CCITT, considering (a) that Recommendation X.200 defines the Reference Model of Open Systems Interconnection for CCITT Applications; (b) that Recommendation X.210 defines the Open System Interconnection (OSI) Layer Service Definition Conventions; (c) that Recommendation X.215 defines the Session Service Definition for Open Systems Interconnection for CCITT Applications; (d) that Recommendation X.216 defines the Presentation Service Definition of Open Systems Interconnection for CCITT Applications; (e) that Recommendation X.220 specifies the use of X.200 series protocols in CCITT Applications; ( f) that Recommendation X.227 specifies the Association Control Protocol Specification for Open Systems interconnection for CCITT Applications; (g) that Recommendation X.410-1984 specifies the protocol for Remote Operation and Reliable Transfer Server for Message Handling Systems; and (h) that there is a need for common Association Control to support various applications, unanimously declares that this Recommendation defines the Association Control Service of Open Systems Interconnection for CCITT Applications as given in the Scope and Field of Application. CONTENTS 0 Introduction 1 Scope and field of application 2 References 3 Definitions 3.1 Reference model definitions 3.2 Naming and addressing definitions 3.3 Service conventions definitions 3.4 Presentation service definitions 3.5 ACSE service definitions 4 Abbreviations 5 Conventions 6 Basic concepts 7 Service overview 8 Relationship with other ASEs and lower layer services 8.1 Other application-service-elements 8.2 Presentation-service 8.3 Session-service 9 Service definition 9.1 A-ASSOCIATE service 9.2 A-RELEASE service 9.3 A-ABORT service 9.4 A-P-ABORT service 10 Sequencing Information 10.1 A-ASSOCIATE 10.2 A-RELEASE 10.3 A-ABORT 10.4 A-P-ABORT Annex A - Usage of ACSE services to achieve compatibility with CCITT Recommendation X.410-1984, and the basic facilities of the 1988 Message Handling series of CCITT Recommendations 1 Recommendation X.217 and ISO 8649 [Information processing systems - Open Systems Interconnection - Service definition for the Association Control Service Element] were developed in close collaboration and are technically aligned, except for the differences noted in Appendix I. Rec. X.217 PAGE1 A.1 Compatibility requirements A.2 Principles for ensuring compatibility A.3 Usage of Association Control services to ensure compatibility with X.410-1984 A.3.1 A-ASSOCIATE A.3.2 A-RELEASE A.3.3 A-ABORT A.3.4 A-P-ABORT A.3.5 State Table Appendix I - Differences between Recommendation X.217 and ISO International Standard 8649. 0 Introduction 0.1 This Recommendation is one of a set of Recommendations produced to facilitate the interconnection of information processing systems. It is related to other Recommendations in the set as defined by the Reference Model for Open Systems Interconnection (X.200). The reference model subdivides the area of standardization for interconnection into a series of layers of specification, each of manageable size. 0.2 The goal of Open Systems Interconnection is to allow, with a minimum of technical agreement outside the inter-connection recommendations, the interconnection of information processing systems: - from different manufacturers; - under different managements; - of different levels of complexity; and - of different technologies. 0.3 This Recommendation recognizes that application-processes may wish to communicate with each other for a wide variety of reasons. However, any communication will require the performance of certain services independent of the reasons for communication. The application-service-element defined herein provides such services. 0.4 This Recommendation defines services provided by the application service element for application-association control: the Association Control Service Element (ACSE). The ACSE provides basic facilities for the control of an application-association between two application-entities which communicate by mea s of a presentation- connection. 0.5 The use of services defined in this Recommendation is also governed by the use of the presentation-service (X.216) and the session-service (X.215). 0.6 It is recognized that, with respect to ACSE Quality of Services (QOS), described in S 9, work is still in progress to provide an integrated treatment of QOS across all layers of the OSI Reference Model, and to ensure that the individual treatments in each layer service satisfy overall QOS objectives in a consistent manner. As a consequence, a change may be made to this Recommendation at a later time which reflects further QOS developments and integration. 1 Scope and field of application This Recommendati n defines ACSE services for application- association control in an open systems interconnection environment. The ACSE services are provided by the use of the ACSE protocol (X.227) in conjunction with the presentation-service (X.216). The ACSE services assume as a minimum the use of the presentation-service Kernel functional unit. This Recommendation does not specify individual implementations or products nor does it constrain the implementation of entities and interfaces within a computer system. No requirement is made for conformance to this Recommendation. 2 References Recommendation X.200 Reference Model of Open Systems Interconnection for CCITT applications. (See also ISO 7498-1) Recommendation X.210 OSI layer service definition PAGE2 Rec. X.217 conventions. (See also ISO TR8509) Recommendation X.215 Session service definition for Open Systems Interconnection for CCITT applications. (See also ISO 8326 and ISO 8326 Addendum 2). Recommendation X.216 Presentation service definition for Open Systems Interconnection for CCITT applications. (See also ISO 8822). Recommendation X.225 Session protocol specification for Open Systems Interconnection for CCITT applications. (See also ISO 8327 and ISO 8327 Addendum 2). Recommendation X.227 Association Control protocol specification for Open Systems Interconnection for CCITT applications. (See also ISO 8650). Recommendation X.410-1984 CCITT Recommendation X.410: Message Handling Systems: Remote Operation and Reliable Transfer Server. ISO 7498-3 Information processing systems - Open Systems Interconnection - Basic Reference Model - Part 3: Naming and Addressing. 3 Definitions 3.1 Reference model definitions This Recommendation is based on the concepts developed in X.200 and makes use of the following terms defined in it: a) Application Layer; b) application-process; c) application-entity; d) application-service-element; e) application-protocol-data-unit; f ) application-protocol-control-information; g) presentation-service; h) presentation-connection; i) session-service; j ) session-protocol; k) session-connection. 3.2 Naming and addressing definitions This Recommendation makes use of the following terms defined in ISO 7498-3; a) application-process title; b) application-entity qualifier; c) application-entity title2; d) application-process invocation-identifier; e) application-entity invocation-identifier; and f ) presentation address. 3.3 Service conventions definitions This Recommendation makes use of the following terms defined in X.210: a) service-provider; b) service-user; c) confirmed service; d) non-confirmed service; e) provider-initiated service; f ) primitive; g) request (primitive); h) indication (primitive); i) response (primitive); and j ) confirm (primitive). 3.4 Presentation service definitions This Recommendation makes use of the following terms defined in Recommendation X.216: 2 As defined in ISO 7498-3, an application-entity title is composed of an application-process title and an application-entity qualifier. The ACSE provides for the transfer of an application-entity title value by the transfer of its component values. Rec. X.217 PAGE1 a) abstract syntax; b) abstract syntax name; c) default context; d) defined context set; e) functional unit [presentation]; f ) normal mode [presentation]; g) presentation context; h) presentation data value; and i) X.410-1984 mode [presentation]. 3.5 ACSE service definitions For the purpose of this Recommendation, the following definitions apply: 3.5.1 application-association; association A cooperative relationship between two application-entities, formed by their exchange of application-protocol-control-information through their use of presentation-services. 3.5.2 application context An explicitly identified set of application-service-elements, related options and any other necessary information for the interworking of application-entities on an application-association. Note - This definition is subject to refinement as a result of ongoing work in the area of the Application Layer structure. 3.5.3 Association Control Service Element The particular application-service-element defined in this Recommendation. 3.5.4 ACSE service-user The part of the application-entity which makes use of ACSE services. 3.5.5 ACSE service-provider An abstraction of the totality of those entities which provide ACSE services to peer ACSE service-users. 3.5.6 requestor The ACSE service-user which issues the request primitive for a particular ACSE service. For a confirmed service, it also receives the confirm primitive. 3.5.7 acceptor f for a particular ACSE service. For a confirmed service, it also issues the response primitive. 3.5.8 association-initiator The ACSE service-user which initiates a particular association, i.e. the requestor of the A-ASSOCIATE service which establishes the association. 3.5.9 association-responder The ACSE service-user which is not the initiator of a particular association, i.e. the acceptor of the A-ASSOCIATE service which establishes the association. 3.5.10 normal mode The mode of ACSE operation which results in the transfer of ACSE semantics, using the presentation-service. 3.5.11 X.410-1984 mode The mode of ACSE operation which allows ACSE service-users to interwork using the protocol specified in CCITT Recommendation X.410 1984. The use of this mode results in no transfer of ACSE semantics. 3.5.12 disrupt A service procedure is disrupted by another service procedure if the second service results in service primitives not being used as specified for the procedure of the first service. 4 Abbreviations The following abbreviations are used in this Recommendation. ACSE Association Control Service Element AE application-entity ASE application-service-element OSI Open Systems Interconnection PAGE2 Rec. X.217 QOS Quality of Service 5 Conventions 5.1 This Recommendation defines services for the ACSE following the descriptive conventions defined in Recommendation X.210. In ' 9, the definition of each ACSE service includes a table which lists the parameters of its primitives. For a given primitive, the presence of each parameter is described by one of the following values. blank not applicable C conditional M mandatory P subject to conditions defined in X.216 U user option i is semantically equal to the value to its left in the table. 6 Basic concepts 6.1 The reference model (X.200) represents communication between a pair of application-processes (APs) in terms of communication between their application-entities (AEs) using the presentation-service. The functionality of an AE is factor d into a number of application- service-elements (ASEs). The interaction between AEs is described in terms of the use of their ASEs' services. 6.2 This Recommendation introduces the additional modelling concepts of application-association and application context. 6.3 An application-association is a cooperative relationship between two AEs. It provides the necessary frame of reference between the AEs in order that they may interwork effectively. This relationship s formed by the exchange of application-protocol- control-information between the application-entities through their use of presentation-services. 6.4 An application context is an explicitly identified set of application-service-elements, related options and any other necessary information for the interworking of application-entities on an application association. 7 Service overview 7.1 This Recommendation defines the following services for the control of a single association a) A-ASSOCIATE; b) A-RELEASE; c) A-ABORT; and d) A-P-ABORT. 7.2 The A-ASSOCIATE service causes the start of use of an association by those ASE procedures identified by the value of Application Context Name parameter. Note - The use of an association by several ASEs is the subject of ongoing work. 7.3 The A-RELEASE service, if successful, causes the completion of the use of an association by those ASE procedures identified by the application context which is in effect without loss of information in transit. However, the success of the A-RELEASE service optionally may be negotiated. 7.4 The A-ABORT service causes the abnormal release of the association with the possible loss of information in transit. 7.5 The A-P-ABORT service indicates the abnormal release of the association as a result of acti n by the underlying presentation- service with the possible loss of information in transit. o of the following modes: a) normal mode; or b) X.410-1984 mode. 7.7 The normal mode of operation allows the ACSE service-user to take full advantage of the functionality provided by both ACSE and the presentation-service (X.216). n this mode the ACSE service- provider transfers its semantics using the normal mode of the presentation-service. Rec. X.217 PAGE1 7.8 The X.410-1984 mode of operation allows the ACSE service-user to interwork with a peer using the protocol specified by the CCITT Recommendation X.410-1984. In this mode, the ACSE service-provider does not transfer any semantics of its own and uses the X.410-1984 mode of the presentation-service. 8 Relationship with other ASEs and lower layer services 8.1 Other application-service-elements 8.1.1 The ACSE is intended to be used with other ASEs in order to support a specific information processing task. Therefore, it is expected that the ACSE will be included in all application context specifications. 8.1.2 The collection of the ACSE and other ASE(s) included in an application context are required to use the facilities of the presentation-service in a coordinated manner. 8.2 Presentation-service 8.2.1 A one-to-one corresponden e exists between an application- association and a presentation-connection. 8.2.2 The ACSE services require access to the P-CONNECT, P-RELEASE, P-U-ABORT and P-P-ABORT services. The ACSE services neither use nor constrain the use of any other presentation service. 8.2.3 The requestor and acceptor of the A-ASSOCIATE service determine the mode, the default presentation context, and the initial defined context set of the underlying presentation-connection using the following A-ASSOCIATE parameter: - Mode; - Presentation Requirements; - Presentation Context Definition List; - Presentation Context Definition Result List; - Default Presentation Context Name; and - Default Presentation Context Result. spe specified in X.227 for the ACSE application-protocol-data-units. Note - The ACSE service-provider is aware of the presentation context which contains its abstract syntax by a local mechanism. 8.2.5 If the requestor specifies the value ;X.410-1984+ for the Mode parameter, the ACSE service-provider does not transfer ACSE semantics and therefore does not require a presentation context for its abstract syntax. Any user information which the ACSE service-provider transfers for its service-user uses the unnamed default presentation context for the X.410-1984 mode of the presentation-service (X.216). Note - Table 2/X.217 indicates the A-ASSOCIATE service parameters which are not used in the X.410-1984 mode. None of the presentation context related parameters are used. 8.3 Session-service 8.3.1 Using the Session Requirements parameter, the A-ASSOCIATE service requestor and acceptor determine the functional units for the underlying session-service (X.215). 8.3.2 The rules and parameter value length restrictions of the underlying session-service affect ACSE service . The ACSE service- user must be aware of these constraints. Note - Some examples of these constraints are: a) Version 1 of the session-protocol (X.225) imposes user data length restrictions which affect ACSE primitive parameters. Some special considerations apply to the A-ABORT services (see ' 9.3). b) The choice of session functional units for a particular association affects the rules for the use of ACSE services. For example, the selection of session tokens controls the possibilities of negotiated release and release collisions. 9 Service definition The ACSE services are listed in Table 1/X.217. TABLE 1/X.217 ACSE-services Service Type A-ASSOCIATE Confirmed A-RELEASE Confirmed A-ABORT Non-confirmed A-P-ABORT Provider-initiated PAGE2 Rec. X.217 9.1 A-ASSOCIATE Service The A-ASSOCIATE service is used to cause the beginning of the use of an association; it is a confirmed service. 9.1.1 A-ASSOCIATE Parameters Table 2/X.217 lists the A-ASSOCIATE service parameters. In addition, groups of parameters are defined for reference by other ASEs as follows: a) Calling AE Title is the composite of the Calling AP Title and the Calling AE Qualifier parameters; b) Called AE Title is the composite of the Called AP Title and the Called AE Qualifier parameters; c) Responding AE Title is the composite of the Responding AP Title and the Responding AE Qualifier parameters; The two components of the AE title (AP title and AE qualifier) are defined in ISO 7498-3. Table 2/X.217 [T2.217], p. TABLE 2/X.217 A-ASSOCIATE parameters Parameter name Request Indicat Respons Confirm ion e ation Mode U M (=) Application context name a) M M (=) M M (=) Calling AP title a) U C (=) Calling AE qualifier a) U C (=) Calling AP invocation-identifier a) Rec. X.217 PAGE1 U C (=) Calling AE invocation-identifier a) U C (=) Called AP title a) U C (=) Called AE qualifier a) U C (=) Called AP invocation-identifier a) U C (=) Called AE invocation-identifier a) U C (=) Responding AP title a) U C (=) PAGE2 Rec. X.217 Responding AE qualifier a) U C (=) Responding AP invocation-identifier a) U C (=) Responding AE invocation-identifier a) U C (=) User information U C (=) U C (=) Result M M (=) Result source M Diagnostic a) U Rec. X.217 PAGE1 C (=) Calling presentation address P P Called presentation address P P Responding presentation address P P Presentation context definition list a) P P Presentation context definition result list a) P P P Default presentation context name a) P P PAGE2 Rec. X.217 Default presentation context result a) P P Quality of service P P P P Presentation requirements a) P P P P Session requirements P P P P Initial synchronization point serial number P P P P Initial assignment of tokens P P P P Session-connection identifier a) P P Rec. X.217 PAGE1 P P a) Not used in X.410-1984 mode. 9.1.1.1 Mode This parameter specifies the mode in which the ACSE services will operate for this association. It takes one of the following symbolic values: - normal; or - X.410-1984. If this parameter is not included on the request primitive, the default value of ╗normal½ is used by the ACSE service provider. This parameter is always present on the indication primitive. 9.1.1.2 Application Context Name This parameter identifies the application context proposed by the requestor. The acceptor returns either the same or a different name. The returned name specifies the application context to be used for this association. Note - The offer of an alternate application context by the acceptor provides a possible mechanism for limited negotiation. However, the semantics and rules for this exchange are entirely user specific. If the requestor cannot operate in the acceptor's application context, it may issue an A-ABORT request primitive. 9.1.1.3 Calling AP Title This parameter identifies the AP which contains the requestor of the A-ASSOCIATE service. 9.1.1.4 Calling AE Qualifier This parameter identifies the particular AE of the AP which contains the requestor of the A-ASSOCIATE service. 9.1.1.5 Calling AP Invocation-identifier This parameter identifies the AP invocation which contains the requestor of the A-ASSOCIATE service. 9.1.1.6 Calling AE Invocation-identifier This parameter identifies the AE invocation which contains the requestor of the A-ASSOCIATE service. 9.1.1.7 Called AP Title This parameter identifies the AP which contains the intended acceptor of the A-ASSOCIATE service. 9.1.1.8 Called AE Qualifier This parameter identifies the particular AE of the AP which contains the intended acceptor of the A-ASSOCIATE service. 9.1.1.9 Called AP Invocation-identifier This parameter identifies the AP invocation which contains the intended acceptor of the A-ASSOCIATE service. 9.1.1.10 Called AE Invocation-identifier This parameter identifies the AE invocation which contains the intended acceptor of the A-ASSOCIATE service. 9.1.1.11 Responding AP Title This parameter identifies the AP which contains the actual acceptor of the A-ASSOCIATE service. 9.1.1.12 Responding AE Qualifier This parameter identifies the particular AE of the AP which contains the actual acceptor of the A-ASSOCIATE service. 9.1.1.13 Responding AP Invocation-identifier This parameter identifies the AP invocation which contains the actual acceptor of the A-ASSOCIATE service. 9.1.1.14 Responding AE Invocation-identifier This parameter identifies the AE invocation which contains the actual acceptor of the A-ASSOCIATE service. 9.1.1.15 User Information Either the requestor or the acceptor may optionally include user information. Its meaning depends on the application context which accompanies the primitive. Note - For example, this parameter may be used to carry the initialization information of other ASEs included in the application PAGE2 Rec. X.217 context specified by the value of the accompanying Application Context Name parameter. 9.1.1.16 Result3 This parameter is provided by either the acceptor, by the ACSE service-provider, or by the presentation service-provider. It indicates the result of using the A-ASSOCIATE service. It takes one of the following symbolic values: - accepted; - rejected (permanent); or - rejected (transient). 9.1.1.17 Result Source The value of the parameter is suppli d by the ACSE service- provider. It identifies the creating source of the Result parameter and the Diagnostic parameter, if present. It takes one of the following symbolic values: - ACSE service-user; - ACSE service-provider; or - presentation service-provider. If the Result parameter has the value ╗accepted½, the value of this parameter is ╗ACSE service-user½. 9.1.1.18 Diagnostic This parameter is only used if the Result parameter has the value of ╗rejected (permanent)½ or ╗rejected (transient)½. Optionally, it can be used to provide diagnostic information about the result of the A-ASSOCIATE service. If the Result Source parameter h s the value ╗ACSE service- provider½, it takes one of the following symbolic values: - no reason given; or - no common ACSE version. If the Result Source parameter h s the value ╗ACSE service- user½, it takes one of the following symbolic values: - no reason given; - application context name not supported; - calling AP title not recognized; - calling AE qualifier not recognized; - calling AP invocation-identifier not recognized; - calling AE invocation-identifier not recognized; - called AP title not recognized; - called AE qualifier not recognized; - called AP invocation-identifier not recognized; or - called AE invocation-identifier not recognized. 9.1.1.19 Calling Presentation Address This parameter is as defined in Recommendation X.216. 9.1.1.20 Called Presentation Address This parameter is as defined in Recommendation X.216. 9.1.1.21 Responding Presentation Address This parameter is as defined in Recommendation X.216. 9.1.1.22 Presentation Context Definition List This parameter is as defined in Recommendation X.216. 9.1.1.23 Presentation Context Definition Result List This parameter is as defined in Recommendation X.216. 9.1.1.24 Default Presentation Context Name This parameter corresponds to the Default Context Name parameter defined in Recommendation X.216. 9.1.1.25 Default Presentation Context Result This parameter corresponds to the Default Context Result parameter defined in Recommendation X.216. 9.1.1.26 Quality of Service This parameter is as defined in Recommendation X.216. 3 It is recognized that, with respect to this parameter, work is still in progress to provide an integrated treatment across all layers of the OSI Reference Model. As a consequence, a change may be made to this Recommendation at a later time which reflects further developments and integration. Rec. X.217 PAGE1 9.1.1.27 Presentation Requirements This parameter is as defined in Recommendation X.216. 9.1.1.28 Session Requirements This parameter is as defined in Recommendation X.216. 9.1.1.29 Initial Synchronization Point Serial Number This parameter is as defined in Recommendation X.216. 9.1.1.30 Initial Assignment of Tokens This parameter is as defined in Recommendation X.216. 9.1.1.31 Session Connection Identifier This parameter is as defined in Recommendation X.216. 9.1.2 A-ASSOCIATE service procedure 9.1.2.1 The A-ASSOCIATE service procedure has a one-to-one correspondence with the P-CONNECT service defined in Recommendation X.216. When the A-ASSOCIATE service is used, the association is created simultaneously with the creation of the underlying presentation-connection. 9.1.2.2 An ACSE service-user which desires to establish an association issues an A-ASSOCIATE request primitive. The called AE is identified by parameters of the request primitive. The requestor cannot issue any primitives except an A-ABORT request primitive until it receives an A-ASSOCIATE confirm primitive. 9.1.2.3 The ACSE service-provider issues an A-ASSOCIATE indication primitive to the acceptor. 9.1.2.4 The acceptor accepts or rejects the association by sending an A-ASSOCIATE response primitive with an appropriate Result parameter. ACSE service-provider issues an A-ASSOCIATE confirm primitive having the same Result parameter. The Result Source parameter is assigned the symbolic value of ╗ACSE service-user½. 9.1.2.5 If the acceptor accepts the association, the association is available for use. Requestors in both AEs may now use any service provided by the ASEs included in the application context which in effect (with the exception of A-ASSOCIATE). 9.1.2.6 If the acceptor rejects the association, the association is not established. 9.1.2.7 The ACSE service-provider may not be capable of supporting the requested associatio . In this situation, it returns an A- ASSOCIATE confirm primitive to the requestor with an appropriate RESULT parameter. The Result Source parameter is appropriately assigned either the symbolic value of ╗ACSE service-provider½ or ╗presentation service-provider½. The indication primitive is not issued. The association is not established. 9.1.2.8 A requestor in either AE may disrupt the A-ASSOCIATE service procedure by issuing an A-ABORT request primitive. The acceptor receives an A-ABORT indication primitive. The association is not established. 9.2 A-Release service The A-RELEASE service is used by a requestor in either AE to cause the completion of the use of an association; it is a confirmed service. If the session Negotiated Release functional unit was selected for the association, the acceptor may respond negatively (see S 8.3.2). This causes t e unsuccessful completion of the A- RELEASE service and the continuation of the association without loss of information in transit. 9.2.1 A-RELEASE parameters Table 3/X.217 lists the A-RELEASE parameters. TABLE 3/X.217 A-RELEASE parameters Parameter name Request Indication Response Confirmatio n Reason a) U C (=) U C (=) User information a) U C (=) U C (=) Result M M (=) a) Not used in X.410-1984 mode. PAGE2 Rec. X.217 9.2.1.1 Reason When used on the request primitive, this parameter identifies the general level of urgency of the request. It takes one of the following symbolic values: - normal; - urgent; or - user defined. Note - For example, if the session Negotiated Release functional unit was selected for the association, the value ╗urgent½ may be used on the request primitive when the requestor desires to urgently release the association. When used on the response primitive, this parameter identifies information about why the acceptor accepted or rejected the release request. It takes one of the following symbolic values: - normal; - not finished; or - user defined. Note - For example, if the session Negotiated Release functional unit was not selected for the association, the value ╗not finished½ may be used on the response primitive when the acceptor is forced to release the association but wishes to give a warning that it has additional information to send or receive. 9.2.1.2 User information Either the requestor or acceptor may optionally include user information on the request or response primitive. Its meaning depends on the application context which is in effect. 9.2.1.3 Result This parameter is used by the acceptor to indicate if the request to release the association normally is acceptable. It takes one of the following symbolic values: - affirmative; or - negative. 9.2.2 A-RELEASE service procedure 9.2.2.1 The A-RELEASE service procedure has a one-to-one correspondence with the P-RELEASE service defined in Recommendation X.216. When the A-RELEASE service is used, the association is released simultaneously with the release of the underlying presentation-connection. 9.2.2.2 An ACSE service-user which desires to release the association issues an A-RELEASE request primitive. This requestor cannot issue any further primitives other than an A-ABORT request primitive until it receives an A-RELEASE confirm primitive. 9.2.2.3 In order to issue an A-RELEASE request primitive, the requestor is required to meet all the requirements for issui g a P- RELEASE request (see S 8.2). 9.2.2.4 The ACSE service-provider issues an A-RELEASE indication primitive to the acceptor. The acceptor then cannot issue any ACSE primitives other than an A-RELEASE response primitive or an A-ABORT request primitive. 9.2.2.5 The acceptor replies to the A-RELEASE indication primitive by issuing an A-RELEASE response primitive with a Result parameter which has a value of ╗affirmative½ or ╗negative½. The acceptor may give a negative response only if the session Negotiated Release functional unit was selected for the association (see S 8.3). 9.2.2.6 If the acceptor gives a negative reponse, it may once again use any service provided by the ASEs included in the application context which in effect (with the exception of the A-ASSOCIATE service). If it gave a positive response, it cannot issue any further primitives for the association. 9.2.2.7 The ACSE service-provider issues an A-RELEASE confirm primitive with an ╗affirmative½ or ╗negative½ value for the Result parameter. If the value is ╗negative½, the requestor may once again use any of the services provided by the ASEs of the application context which is in effect (with the exception of A-ASSOCIATE). Rec. X.217 PAGE1 9.2.2.8 If the value of the Result parameter is ╗affirmative½, the association and the underlying presentation-connection have been released. 9.2.2.9 A requestor in either AE may disrupt the A-RELEASE service procedure by issuing an A-ABORT request. The acceptor receives n A- ABORT indication. The association is released with the possible loss of information in transit. 9.2.2.10 An A-RELEASE service procedure collision results when requestors in both AEs simultaneously issue an A-RELEASE service primitive. This can occur only when no session tokens are available on the association (see S 8.3). In this situation, both ACSE service users receive an unexpected A-RELEASE indication primitive. The following sequence then occurs to complete the normal release of the association. a) The association-initiator issues an A-RELEASE response primitive. b) The association-responder waits for an A-RELEASE confirm primitive from its peer. When it receives one, it then issues an A-RELEASE response primitive. c) The association-initiator receives an A-RELEASE confirm primitive. 9.2.2.11 The association is released when both ACSE service-users have received an A-RELEASE confirm primitive. 9.3 A-ABORT service The A-ABORT service is used by a requestor in either AE to cause the abnormal release of the association. It is a non-confirmed service. However, because of the possibility of an A-ABORT service procedure collision (see S 10.3.5), the delivery of the indication primitive is not guaranteed. However, both AEs are aware that the association has been released. 9.3.1 A-ABORT parameters Table 4/X.217 lists the A-ABORT parameters. TABLE 4/X.217 A-ABORT parameters Parameter name Request Indication Abort source a) M User information U C (=) a) Not used in X.410-1984 mode. 9.3.1.1 Abort Source This parameter, whose value is supplied y the ACSE service- provider, indicates the initiating source of this abort. It takes one of the following symbolic values: - ACSE service-user; or - ACSE service-provider. 9.3.1.2 User Information The requestor may optionally include user information on the request primitive. Its meaning depends on the application context which is in effect. Note - When ACSE is supported with version 1 of the session- protocol (X.225), this parameter is subject to length restrictions mentioned in S 8.3. For use with version 1, the A-ABORT service procedure does not transfer any of its own semantics, thus allowing the maximum possible length for presentation data value(s) of the User Information parameter. In this situation, the Abort Source parameter of the A-ABORT indication primitive always indicates ╗ACSE service-user½. 9.3.2 A-ABORT service procedure 9.3.2.1 The A-ABORT service procedure has a one-to-one correspondence with the P-U-ABORT service defined in Recommendation X.216. When the A-ABORT service is used, the association is abnormally released simultaneously with the abnormal release of the underlying presentation-connection. 9.3.2.2 An ACSE service-user which desires to abnormally release PAGE2 Rec. X.217 the association issues the A-ABORT request primitive. This requestor cannot issue any further primitives for the association. 9.3.2.3 The ACSE service-provider issues an A-ABORT indication primitive to the acceptor. The ACSE service-provider assigns the value of ╗ACSE service-user½ for the Abort Source parameter. The association and the underlying presentation-connection have been released. 9.3.2.4 The ACSE service-provider may itself cause the abnormal release of the association because of internal errors detected by it. In this case, the ACSE service-provider issues A-ABORT indication primitives to acceptors in both AEs. The ACSE service-provider assigns the value of ╗ACSE service-provider½ to the Abort Source parameter. The User Information parameter is not used. 9.4 A-P-ABORT service The A-P-ABORT service is used by the ACSE service-provider to signal the abnormal release of the association due to problems in services below the Application Layer. This occurrence indicates the possible loss of information in transi . A-P-ABORT is a provider- initiated service. 9.4.1 A-P-ABORT parameter Table 5/X.217 lists the A-P-ABORT parameter. TABLE 5/X.217 A-P-ABORT parameter Parameter name Indication Provider reason P Provider Reason: This parameter is as defined in Recommendation X.216. 9.4.2 A-P-ABORT service procedure When the ACSE service-provider detects an error reported by the underlying presentation-service, it issues A-P-ABORT indication primitives to acceptors in both AEs. The association is abnormally released. Requestors in both AEs cannot issue any further primitives for the association. 10 Sequencing information This clause defines the interaction among the ACSE service procedures for a particular association. 10.1 A-ASSOCIATE 10.1.1 Type of service A-ASSOCIATE is a confirmed service. 10.1.2 Usage restrictions The A-ASSOCIATE service is not used on an established association. 10.1.3 Disrupted service procedures The A-ASSOCIATE service procedure does not disrupt any other service procedure. 10.1.4 Disrupting service procedures The A-ASSOCIATE service procedure is disrupted by the A-ABORT service procedures. 10.1.5 Collisions An A-ASSOCIATE service procedure collision results when requestors in both AEs simultaneously issue an A-ASSOCIATE request primitive for each othe . Both ACSE service-users are issued A- ASSOCIATION indication primitives which represent distinct associations. Both can choose to accept or reject the indicated association by issuing an A-ASSOCIATE response primitive with the appropriate value for its Result parameter. This will result in the establishment of none, one or two associations. Note - If an AE has several concurrent associations, a local mechanism is needed to distinguish between them. 10.2 A-RELEASE 10.2.1 Type of service A-RELEASE is a confirmed service. 10.2.2 Usage restrictions Rec. X.217 PAGE1 The A-RELEASE service is only used on an established association. 10.2.3 Disrupted service procedures The A-RELEASE service procedure does not disrupt any other service procedure, except that an A-ABORT indication is suppressed following issuance of an A-RELEASE response, and that an A-P-ABORT indication is suppressed following issuance of an A-RELEASE response or confirm. 10.2.4 Disrupting service procedures The A-RELEASE service procedure is disrupted by the A-ABORT or A-P-ABORT service procedures. 10.2.5 Collisions An A-RELEASE service procedure collision results when requestors in both AEs simultaneously issue an A-RELEASE request primitive. The processing of A-RELEASE service procedure collisions is described in S 9.2.2. 10.2.6 Further sequencing information The use of the A-RELEASE service is subject to the constraints on t e S- RELEASE service defined in Recommendation X.215 (see S 8.3). 10.3 A-ABORT 10.3.1 Type of service A-ABORT is a non-confirmed service. 10.3.2 Usage restrictions The A-ABORT service has effect only when used on an association in the process of establishment, on an established association, or on an association in the process of being released. 10.3.3 Disrupted service procedures The A-ABORT servi e procedure disrupts the A-ASSOCIATE, A- RELEASE and A-P-ABORT service procedures. 10.3.4 Disrupting service procedures The A-ABORT service procedure is disrupted by the A-P-ABORT service procedure and by the issuance of an A-RELEASE response. 10.3.5 Collisions An A-ABORT service procedure collision results when requestors in both AEs simultaneously issue the A-ABORT request primitive. The collision processing is governed by the P-U-ABORT service defined in Recommendation X.216. In this situation, neither A-ABORT indication primitive is issued. 10.3.6 Further sequencing information Any use of the A-ABORT service results in the abnormal release of the association, or the abnormal termination of the A-ASSOCIATE service procedure or the A-RELEASE service procedure with possible loss of information. 10.4 A-P-ABORT 10.4.1 Type of service A-P-ABORT is a provider-initiated service. 10.4.2 Usage restrictions No restrictions are placed on the occurrence of this service. 10.4.3 Disrupted service procedures The A-P-ABORT service procedure disrupts all other service procedures. 10.4.4 Disrupting service procedures The A-P-ABORT service procedure is disrupted by the A-ABORT service procedure and by the issuance of an A-RELEASE response or confirm. ANNEX A (to Recommendation X.217) Usage of ACSE services to achieve compatibility with CCITT Recommendation X.410-1984, and the basic facilities of the 1988 Message Handling series of CCITT Recommendations A.1 Compatibility requirements Recommendation X.410, which was adopted by CCITT in 1984, has been used in a number of Recommendation X.400 Message Handling products available or under development. It is essential that the systems following Recommendation PAGE2 Rec. X.217 X.410-1984 be able to interwork with OSI systems. This principle has been guiding the development of the OSI ACSE and Presentation service and protocol, which has been conducted in very close cooperation between CCITT and ISO. This Annex shows how the ACSE service is to be used to achieve compatibility with Recommendation X.410-1984, and to support the basic facilities of the 1988 Message Handling series of CCITT Recommendations. Reference is also made to a companion Annex attached to the OSI Presentation service (Recommendation X.216) which shows how OSI Presentation service is to be used in order to achieve compatibility with Recommendation X.410-1984. A.2 Principles for ensuring compatibility The ACSE X.410-1984 mode of operation can be activated resulting in full encoding alignment with X.410-1984 at the session user data level. Its effect is to suppress the generation of explicit ACSE APDUs while maintaining an active ACPM state machine (see Recommendation X.227, Annex B). The layered structure of both protocols, which conforms with the OSI Reference Model, makes it possible to distinguish the Presentation Layer functions and parameters from those of the Application Layer. Based on this layering, the following principles are used to ensure the required compatibility: a) The functions and the corresponding protocol elements of X.410-1984 which belong to the Presentation Layer are integrated into the OSI Presentation protocol, which remains consistent and satisfies the requirements of the whole set of OSI applications. b) The additional functions and protoc l elements of X.410- 1984 are placed in the Application Layer. They are generated by the Reliable Transfer Service Element (RTSE, see Recommendations X.218 and X.228 also Recommendation X.410-1984). They are passed transparently by the ACSE service-provider during association establishment and release by making direct use of the Presentation services. A.3 Usage of Association Control services to ensure compatibility with Recommendation X.410-1984 The following Association Control services are used: A-ASSOCIATE A-RELEASE A-ABORT A-P-ABORT The use of these services is explained in SS A.3.1-A.3.5. Note - RTORQ, RTOAC, RTORJ and RTAB are names given to APDUs generated by the RTSE protocol machine. A.3.1 A-ASSOCIATE An association is established and the X.410-1984 mode of ACSE operation is activated with the following combination of A-ASSOCIATE service parameters: a) Mode parameter must be set to ╗X.410-1984½ on request primitive; b) Presentation Requirements parameter must specify the kernel. c) Session Requirements parameter must be set according to X.410-1984; and d) User Information: 1) On the request and indication primitives, this parameter must contain an RTORQ APDU. 2) On the response and confirmation primitives, it must contain a RTOAC APDU if the association has been accepted, or a RTORJ APDU if the association has been rejected. 3) If the ACSE service-provider has rejected the request, then this parameter is not used. Rec. X.217 PAGE1 All other A-ASSOCIATE parameters must be absent or as defined by the Presentation Service and its Annex concerning its use for X.410-1984 compatibility (Recommendation X.216). Following the occurrence of an A-ABORT or A-P-ABORT service event, the initiating RTSE may use the A-ASSOCIATE service an implementation dependent number of times to attempt recovery. This use of the service has all parameters absent except for Presentation User Data which must contain the recovery data from the RT-OPEN service. A.3.2 A-RELEASE The association is released by the use of this service with only the Result parameter present. The rules governing the use f A- RELEASE are as in the main body of this document and are identical to those for P-RELEASE. A.3.3 A-ABORT Either ACSE service-user may signal to its peer that it has a problem and attempt to force the release of an association by using A ABORT service with all parameters absent except for the Presentation User data parameter, which must contain an RTAB APDU. The association is released, and the initiating RTSE may use the A-ASSOCIATE service to attempt to obtain a new association over which it can execute its recovery procedures. A.3.4 A-P-ABORT Either ACSE service-provider may signal that it has a problem (internally or with the services which underlie it) to its peer and force the release of an association by using the A-P-ABORT service as defined in Recommendation X.216. The association is released, and the initiating RTSE may use the A-ASSOCIATE service to attempt to obtain a new association over which it can execute its recovery procedures. A.3.5 State Table The state table which governs the operation of the ACSE in X.410-1984 mode is given in Annex B of Recommendation X.227. APPENDIX I (to Recommendation X.217) Differences between Recommendation X.217 and ISO International Standard 8649 I.1 Recommendation X.217 and ISO 8649 are technically aligned, with the following minor exceptions: I.2 In S 10 on Sequencing Information this Recommendation states that the A-ABORT and A-P-ABORT services are mutually disruptive, when they collide (see SS 10.3.3 and 10.4.4). ISO 86 9 states that A-P- ABORT cannot be disrupted (see SS 10.3.3 and 10.4.4). I.3 In S 10 on Sequencing Information this Recommendation states that an A-ABORT indication is suppressed following issuance of n A- RELEASE response, and that an A-P-ABORT indication is suppressed following issuance of an A-RELEASE response or confirm (see SS 10.2.3, 10.3.4 and 10.4.4). ISO 8649 states that the A-RELEASE service procedure does not disrupt any other service procedure (see SS 10.2.3, 10.3.4 and 10.4.4). I.4 This Recommendation contains an Annex A, which has not been included in ISO 8649. Annex A shows how the OSI Association Control service is to be used in order to achieve compatibility with Recommendation X.410-1984 and to support the basic facilities of the 1988 message handling services of CCITT Recommendations (the X.400 series). I.5 There is no equivalent of this Appendix I in ISO 8649. PAGE2 Rec. X.217